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Preface 


For quite a while, I’ve been disturbed by the emphasis on language in com- 
puter science. One result of that emphasis is programmers who are C++ 
experts but can’t write programs that do what they’re supposed to. The 
typical computer science response is that programmers need to use the right 
programming /specification/development language instead of/in addition to 
C++. The typical industrial response is to provide the programmer with 
better debugging tools, on the theory that we can obtain good programs by 
putting a monkey at a keyboard and automatically finding the errors in its 
code. 

I believe that the best way to get better programs is to teach program- 
mers how to think better. Thinking is not the ability to manipulate lan- 
guage; it’s the ability to manipulate concepts. Computer science should be 
about concepts, not languages. But how does one teach concepts without 
getting distracted by the language in which those concepts are expressed? 
My answer is to use the same language as every other branch of science 
and engineering—namely, mathematics. But how should that be done in 
practice? This note represents a small step towards an answer. It doesn’t 
discuss how to teach computer science; it simply addresses the preliminary 
question of what is computation. 
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Appendix: The Definition of z(c) 


1 Introduction 


Much of computer science is about state machines. This is as obvious a 
remark as saying that much of physics is about equations. Why state some- 
thing so obvious? 

Imagine a world in which physicists did not have a single concept of 
equations or a standard notation for writing them. Suppose that physicists 


studying relativity wrote the “einsteinian” m Z c? — E instead of E = mce?, 
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while those studying quantum mechanics wrote the “heisenbergian” E M : 
and that physicists were so focused on the syntax that few realized that these 
were two ways of writing the same thing. In such a world, it would be worth 
observing that relativity and quantum mechanics both used equations. 

This imagined world of physics seems absurd. Its analog is the reality 
of computer science today. Computation is a major topic of computer sci- 
ence, and almost every object that computes is naturally viewed as a state 
machine. Yet computer scientists are so focused on the languages used to 
describe computation that they are largely unaware that those languages 
are all describing state machines. 

Teaching our imaginary physicists that einsteinians and heisenbergians 
are different ways of writing equations would not lead to any new physics. 
The equations of relativity are different from those of quantum mechanics. 
Similarly, realizing that so much of computer science is about state machines 
might not change the daily life of a computer scientist. The state machines 
that arise in different fields of computer science differ in important ways, 
and they may be best described with different languages. Still, it seems 
worthwhile to point out what they have in common. 

State machines provide a framework for much of computer science. They 
can be described and manipulated with ordinary, everyday mathematics— 
that is, with sets, functions, and simple logic. State machines therefore 
provide a uniform way to describe computation with simple mathematics. 

The obsession with language is a strong obstacle to any attempt at uni- 
fying different parts of computer science. When one thinks only in terms 
of language, linguistic differences obscure fundamental similarities. Simple 
ideas can become complicated when they must be expressed in a particular 
language. A recurring theme is the difficulty that arises when necessary 
concepts cannot be introduced either because the language has no way of 
expressing them or because they are considered to be politically incorrect. 
(A number of different terms have been used to mean politically correct, 
such as “fully abstract”, “observable”, and “denotational” .) 


The purpose of this note is to indicate how computation is expressed with 
state machines and how doing so can clarify the concepts underlying the 
disparate languages for describing computations. Section 2 explains what 
state machines are and how they can describe things that compute, and 
Section 3 considers the important example of computer programs. Section 4 
shows how state machines are described with mathematics. Section 5 delves 
more deeply into the use of state machines in the area of computer science 
that can be called correctness. 

Many of the ideas expressed here appear, sometimes implicitly, in the 
work of Yuri Gurevich and others on Abstract State Machines [7, 13, 15]. 
Much of that work has been motivated by the desire to describe the class of 
effectively executable computations [14]. Readers who have studied Abstract 
State Machines will find much here that is familiar, but viewed from a 
somewhat different perspective. 


2 State Machines 


2.1 Behaviors 


Much of computer science is about computing objects—objects that com- 
pute. I begin by considering what a computation is. There are several ways 
to define computation. For now, I take the simplest: a computation is a 
sequence of steps, which I call a behavior. There are three common choices 
for what a step is, leading to three different kinds of behavior: 


Action Behavior A step is an action, which is just an element of some set 
of actions. An action behavior is a sequence of actions. 


State Behavior A step is a pair (s, t) of states, where a state is an element 
of some set of states. A state behavior is a sequence sı — s2 — 
s3 > --: of states. The step (si, Si+1) represents a transition from 
state s; to state $j41. 


State-Action Behavior A step is a triple (s,a,t), where s and t are 
. š ‘ R : ay 
states and q is an action. A state-action behavior is a sequence sı —> 
a2 a3 cid 
s2 —> s3 —>---. The step (si, aj, Si+1) represents a transition from 


state s; to state 5,41 that is performed by action a;. 


Behaviors can be finite or infinite. A finite behavior is said either to termi- 
nate or to deadlock, depending on whether or not we like its final state (or 
its final action, for action behaviors). When behaviors are expected to be 


finite, sometimes infinite behaviors are said to diverge and finite behaviors 
that end in undesired states are said to abort. 

State and state-action behaviors are essentially equivalent. A state be- 
havior can be regarded as a state-action behavior with only a single dummy 
action |. A state-action behavior can be represented as a state behavior 
whose states are pairs, where s1 > s3 => s3 —* --- is most conveniently 
represented as (L, s1) > (a1, s2) — (a2, 83) +--+. Action behaviors are 
usually specified by defining state-action behaviors and throwing away the 
states. 


2.2 State Machines 


A computing object generates computations. When a computation is a state 
behavior, such an object is naturally defined as a state machine. A state 
machine is usually specified by a set S of states, a set Z of initial states, and 
a next-state relation M on S, so Z C S and N C S x S. It generates all 
state behaviors s1 — s2 — s3 —--- such that: 


Sl. 5s, €Z 
S2. (8;,$i41) E M, for all i. 


S3. If the behavior is finite, then it ends in a state s for which there is no 
state t with (s,t) EN. 


A state-machine is said to be deterministic iff the next-state relation M is 
a function—that is, iff for each state s there is at most one state t with 
(s,t) EN. 

Nondeterministic state machines may also include fairness conditions 
that require certain steps to occur if they are possible. In this case, $3 can 
be a fairness condition that may or may not be required. 

If a computation is a state-action behavior, then a computing object 
is specified with a state-action machine. Such a machine is like a state 
machine except that the next-state relation becomes a next-state set M 
that is a subset of S x A x S, where A is the set of all actions. A state- 
action machine is deterministic iff for every state s there is at most one pair 
(a, t) with (s,a,t) EN. 

Here are a few examples of computing objects and how they are described 
by state or state-action machines. 


Automata Many kinds of automata have been defined, the most well- 
known being the Turing machine. A Turing machine is a state machine 


whose state describes the contents of the tape, the internal state, and 
the position of the read/write head. We can let the set of initial states 
describe all tapes that represent valid inputs, or we can let each pos- 
sible input tape define a different state machine, so the initial-state 
set Z contains only a single initial state. It should be obvious how 
other kinds of automata are also naturally described as state or state- 
action machines—for example, Moore machines, Mealy machines, and 
other finite-state automata; pushdown automata; multi-tape Turing 
machines; and cellular automata. 


von Neumann Computers The state of a von Neumann computer spec- 
ifies the contents of the memory and of all the registers, including a 
program counter (pc) that contains the address of the next instruc- 
tion to be executed. The next-state relation contains the pair (s, t) 
of states iff executing the next instruction (the one specified by pc) in 
state s produces state t. Output can be represented with an output 
register; input can be represented with a read instruction that nonde- 
terministically sets a memory location to an arbitrary value. (There 
are a number of other ways to represent input and output as well.) 
We usually let the set Z of initial states contain all possible states. 
However, if we are interested in a particular program executed on the 
computer, we can let Z be the set of all states containing the program in 
some portion of memory, having legal inputs in the appropriate mem- 
ory locations, and with pc containing the address of the program’s first 
instruction. 


Algorithms An algorithm is usually considered to be a recipe for generat- 
ing behaviors. For a sequential algorithm, computational complexity 
measures how many steps are in the behaviors it generates.' As an 
example of a concurrent algorithm, consider a distributed message 
passing algorithm in which a set P of processes interact by sending 
and receiving messages. A state is the cross product of local states of 
all processes together with the state of the communication medium, 
which describes the messages currently in transit. For a dynamic sys- 
tem in which processes enter and leave, a process that is not currently 
part of the system has a default inactive state. (If there is no bound 
on the number of processes that can become active, then the set P is 


1Some computer scientists think an algorithm is a function from inputs to outputs. If 
that were true, then bubble sort and heap sort would be the same algorithm, since they 
compute the same function. 


infinite.) The next-state relation M is the union of: 


e For each process p in P, a relation Mp that describes the steps 
performed by p. In a typical step, p receives a message and 
responds by sending zero or more messages. If (s,t) is in Np, 
then s and ¢ can differ only in the local state of p and the state 
of the communication medium. 


e A relation C that describes internal steps of the communication 
medium—for example, the loss of one or more messages. If (s, t) 
is in C, then s and ¢ can differ only in the state of the communi- 
cation medium. 


It is also possible to define M so it contains steps that are performed 
simultaneously by multiple processes or by one or more process and 
the communication medium. The use of state machines that allow 
such simultaneous operations is sometimes (rather misleadingly) called 
“true concurrency”. 


BNF Grammars A BNF grammar can be described as a state machine 
whose states are sequences of terminals and/or non-terminals. The 
set of initial states contains only the sequence consisting of the single 
starting non-terminal. The next-state relation is defined to contain 
(s,t) iff s can be transformed to t by applying a production rule to 
expand a single non-terminal. 


Process Algebras A process algebra such as CCS [21] can be described 
by state-action machines whose states are terms of the algebra. The 
next-state set M contains (s,a,t) iff s > t is a transition of the 
algebra. A term defines the state-action machine in which the set of 
initial states contains only that term. 


It would be an absurd trivialization to say that Turing machines and dis- 
tributed algorithms are the same because they are state machines, just as 
it would be absurd to say that relativity and quantum mechanics are the 
same because they use equations. However, we would be suspicious if the 
mathematics used to reason about equations depended on whether they were 
written as einsteinians or as heisenbergians. Likewise, we should be suspi- 
cious if completely different formalisms are used to prove termination of 
Turing machines and of distributed algorithms. On the other hand, there is 
a big difference between finite and infinite sets of states, so we would not be 
surprised if the methods used to prove termination of finite state automata 


and von Neumann computers were different from those used for Turing ma- 
chines and distributed algorithms. (In practice, the number of states of a 
von Neumann computer is so large that one proves its termination by the 
same methods used for infinite-state state machines.) 


2.3 Other Kinds of Computations 


A state machine is a generator of computations. So far, I have taken a 
computation to be a behavior. Other definitions of computation have been 
proposed. I now briefly describe how a state or state-action machine is 
considered to generate them. 

One alternate definition of a computation is a state tree, which is a tree 
whose nodes are labeled by states. A state tree describes the tree of possible 
executions from the root’s state. A state machine generates every state tree 
for which (i) the root node is in the set of initial states and (ii) a node 
labeled with any state s has a child labeled with state t iff (s,t) is in the 
next-state relation. 

We can also define a computation to be a state-action tree, which is a 
state tree whose edges are labeled by actions. A state-action machine can be 
viewed in the obvious way as a generator of state-action trees, where there 
is an edge labeled a from a node labeled with state s to a child labeled with 
state t iff (s,a,t) is in the next-state set. 

As with state-action behaviors, some formalisms delete the state labels 
from state-action trees to obtain action trees with only the edges labeled. 
This leads some to argue that we must describe computations with trees 
because behaviors are not expressive enough. The classic example asserts 
that the two trees 


are generated by different machines that both generate the two action be- 
haviors 


pee Mes ad a 
Hence, it is claimed, two different systems generate the same behaviors. In 
fact, the two systems generate the same behaviors only if political correctness 
prevents mentioning the states, so one views only the actions. The state- 
action behaviors generated by the state-action machines that produce the 


two action trees are different because the machines have different sets of 
states. 

Another definition of a computation is a partially ordered multiset of 
actions, called a pomset for short. A pomset is a set II with an irreflexive 
partial-order relation <, where the elements of II are labeled with actions. 
An element labeled by action a represents an execution of a, and e < 
f means that the action execution represented by e precedes the action 
execution represented by f. If neither e < f nor f < e holds, then the two 
executions are said to be concurrent. The pomsets generated by a state- 
action machine are defined to consist of all pomsets (øo) such that ø is 
a state-action behavior generated by the machine, where z(c) is defined 
intuitively as follows. Dropping the states from o yields an action behavior 
(a sequence of actions) that we can view as a totally ordered multiset of 
actions. (It is a multiset because the same action can appear multiple times 
in the computation.) We define z(c) to be the pomset obtained from this 
totally ordered multiset by eliminating orderings between pairs of elements 
that represent concurrent action executions. Readers interested in pomsets 
will find a precise definition of (øo) in the appendix. 

For deterministic state machines or state-action machines, the trees they 
generate consist of a single path and the pomsets they generate are totally 
ordered. Hence their trees and pomsets are equivalent to behaviors. The 
different kinds of computations differ only for nondeterministic machines. 

Different kinds of computation have different uses. Behaviors are natural 
for discussing termination of a distributed algorithm, which means that all 
of its behaviors are finite. Trees are natural for discussing termination of 
a nondeterministic Turing machine, which usually means that its state tree 
contains at least one leaf node.” It can be difficult to define what fairness 
conditions mean when computations are trees, so computations are most 
often taken to be behaviors when fairness is important. 


2.4 Other Ways to Describe Computations 


Methods for describing computations by writing state machines have been 
criticized for introducing extraneous details. Mentioning certain parts of 
the state has been considered politically incorrect, and methods have been 
proposed that avoid mentioning them—or even mentioning the state at all. 

There is sometimes good reason why some part of the state should not 
be described by a computation. For example, a specification of a memory 


2A nondeterministic Turing machine is usually defined to terminate iff any of its pos- 
sible executions does. 


should describe the sequences of reads and writes that are permitted. The 
contents of the memory can be considered part of the implementation and 
should not be mentioned. Thus, we might describe a memory by a set of 
action behaviors, where an action is something like set location 14 to —7 
or read 83 from location 14. Alternatively, we might describe it as a set of 
state behaviors, where the state describes only the contents of the memory’s 
input and output registers, not the contents of memory locations. 

We can use state machines to write such specifications by simply declar- 
ing the unwanted part of the state to be hidden and not considered to be 
part of a computation [1]. Methods in which a computation is taken to be 
an action behavior often use state-action machines in which the entire state 
is considered hidden—for example, I/O Automata [19]. 

Some computer scientists believe we should not mention the unwanted 
part of the state, even if it is hidden. An alternative is to describe computa- 
tions by a set of axioms—for example, using temporal logic [25]. However, 
this simply does not work in practice for any but the most trivial examples. 
The only practical method for describing nontrivial sets of computations is 
with state machines. Methods that apparently describe computations di- 
rectly without using hidden state work only if they can essentially encode a 
state machine. For example, one can specify a set of computations with a 
relation R between input streams and output streams, where R is defined 
recursively using auxiliary functions that describe the hidden state [8]. 


3 Programs as State Machines 


Programs generate computations, so they are obvious candidates to be 
viewed as state machines. However, most computer scientists seem to think 
about programs primarily in terms of their syntax, not their computations. 
Consider the three C programs of Figure 1 that compute 7!. When asked 
which of them differs the most from the other two, computer scientists usu- 
ally answer Program 3. The reason they give is that Programs 1 and 2 
use iteration while 3 uses recursion, or perhaps that 1 and 2 are imperative 
while 3 is functional. However, iteration and recursion are different ways of 
expressing computations; they do not necessarily express different computa- 
tions. In terms of their computations, it is Program 2 that differs most from 
the other two. The significant steps in computing 7! are the multiplications. 
Programs 1 and 3 perform the same sequence of multiplications, which is 
different from the sequence performed by Program 2. All three produce the 
same result only because multiplication is commutative. (To see this, try 


Program 1: #include <stdio.h> 
main() { int f = 1, i = 2; 
for (i = 1; i <= 7; ++i) f =i * f; 
printf ("%d", f) ; 
} 


Program 2: #include <stdio.h> 
main() { int f = 1, i; 
for (i = 7; 1 < i; --i) f =i * f; 
printf ("%d", f) ; 
} 


Program 3: #include <stdio.h> 
int fact(int i) 
{ return (i == 1) ? 1: i * fact(i-1); } 
main() { printf ("%d", fact(7)); } 


Figure 1: Three C programs for computing 7! . 


replacing “*” with “-” in the programs and running them.) 

To describe a program as a state machine, we must decide what con- 
stitutes a step. How many steps are performed in executing the statement 
f = ix f of the programs in Figure 1? Does a single step change the value 
of f to the product of the current values of i and f? Are the evaluation of 
ix f and the assignment to f two steps? Are there three steps—the reading 
of i, the reading of f, and the assignment to f? 

The output produced by executing a sequential program does not depend 
on how many steps are performed in executing a statement like f = i x f. 
We can make a fairly arbitrary decision of what constitutes a step when 
describing a sequential program as a state machine. For a C program, the 
state will describe what program variables are currently defined, their values, 
the contents of the heap and of the program’s call stack, the current control 
point, and so on. Specifying how to translate any legal C program into 
a state machine essentially means giving an operational semantics to the 
language. Writing an operational semantics is the only practical method 
of formally specifying the meaning of an arbitrary program written in a 
language as complicated as C. 

The output produced by executing a concurrent program can depend 
upon how many separate steps are taken when executing a statement like 


IF 2=1 THEN 1 ELSE n>*(n-— 1)! 


w=1 


Il: 


i€{jEZ:1<j<n} 
Figure 2: Three definitions of n!. 


f = ix f. Errors in concurrent programs often arise because what the 
programmer thinks of as a single step is actually executed as multiple steps. 
The programmer may think evaluating i*f is a single step, but in an actual 
execution a step of a different thread might occur between the reads of i 
and f. 

Most modern multiprocessor computers have weak memory models in 
which a read or write of i or f is not a single step. These memory models 
are usually specified in terms of axioms on computations instead of in terms 
of state machines [3]. We can understand a state machine by mentally 
executing it, but it is extremely difficult to understand the consequences of 
a set of axioms. As a result, it is very hard to write multiprocess programs 
that use unsynchronized reads and writes of shared variables that are correct 
under such memory models. Instead, we usually program in a way that 
permits accurate state-machine descriptions of our programs. For example, 
accesses to shared variables are usually placed in a critical section whose 
execution can be considered to be a single step. When programmers must 
use unsynchronized reads and writes, as in operating system code, they seem 
to use intuitive state machine models of the memory based on a particular 
computer. Their code often does not work on a later-model computer with 
a more highly optimized implementation of the same memory model. 


Just because Programs 1 and 3 of Figure 1 generate the same sequences 
of multiplications does not mean that their differences are unimportant. 
The differences in the other steps they generate may affect their execution 
speeds. For example, function calls are often more expensive than branches. 
Moreover, the way a program is written can affect how easy it is to under- 
stand, and consequently how easy it is to check its correctness. Consider the 
three possible definitions of n! in Figure 2. From the first definition, it is 
more obvious that Program 3 computes 7!. On the other hand, the second 
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definition makes it is easier to see that Program 1 does. With the third 
definition (where no ordering of the multiplications is implied), Programs 
1 and 2 are most easily seen to compute the correct result and could be 
considered most similar. 


4 Describing State Machines 


To use state machines, we need a language for describing them. Any lan- 
guage for describing objects that compute can be viewed as describing state 
machines, so there is a large choice of possible languages. Every computer 
scientist will have her favorite—perhaps actor-based or a form of process 
algebra. I will adopt the one language used in all other branches of sci- 
ence and engineering—namely, mathematics. The formalism underlying this 
mathematics was developed over a century ago and is considered standard 
by most mathematicians. It consists of first-order logic and (untyped) set 
theory.’ Several formal languages exist for expressing this standard mathe- 
matics [2, 18], but I will just use mathematics informally here. 

Since a state machine is described by the sets Z and M, we could simply 
use ordinary set notation to specify these sets. However, there is a simple 
method of representing states that is used by most scientists and engineers. 
A set of states is specified by a collection of state variables and their ranges, 
which are sets of values. A state s assigns to every variable v a value s(v) 
in its range. For example, physicists might describe the state of a particle 
moving in one dimension by variables x (the particle’s position) and p (its 
momentum) whose ranges are the set of real numbers. The state s; at a 
time t is described by the real numbers s(x) and s;(p), which physicists 
usually write z(t) and p(t). 

Scientists and engineers specify a subset of the set of states with a state 
predicate, which is a Boolean-valued formula P whose free variables are 
state variables. We say that a state s satisfies a state predicate P iff P 
equals TRUE when s(v) is substituted for v, for each state variable v. For 
the particle example with real-valued variables x and p, the state predicate 
x = 0 specifies the set of all states s such that s(x) = 0 and s(p) is any real 
number. 

Because most fields of science and engineering study continuous process- 
es, there is no standard way to describe a relation on the set of states. For 
this purposes, I use a transition predicate, which is a Boolean-valued formula 


3There are several slightly different formulations of standard mathematics, but they 
are essentially equivalent for scientific and engineering applications. 
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N whose free variables are primed and/or unprimed state variables. A pair 
(s,t) of states satisfies N iff N equals TRUE when s(v) is substituted for 
v and t(v) is substituted for v’, for each state variable v. For the particle 
example, (x’ = x+1)A(p’ > 2’) specifies the relation consisting of all pairs 
(s,t) of states such that t(x) = s(x) + 1 and t(p) > t(x). 

There is a natural isomorphism between state predicates and subsets 
of the set S of states, where P «+ P iff P is the set of states satisfying 
state predicate P. If P + P and Q - Q, then PAQ = PNQ and 
Pv Q PUQ. Similarly, there is an isomorphism between transition 
predicates and relations on S, where A corresponds to N and V to U under 
the isomorphism. 

To specify a state machine, we give the state variables and their ranges, 
and we write a state predicate Init and a transition predicate Next. I illus- 
trate this with a state machine that describes the following C code, where 
execution from one label to the next is considered to be a single step. 


Program 4 
int i, f = 1; 
test: if (i >1) mult:{f=ixf; --i; goto test; }; 
done: 


(The int declaration is considered to be a specification of the starting state 
and not a statement to be executed.) We can describe Program 4 with the 
variables i, f, and pc, where i and f have as range the set of integers and 
the range of pc is the set { “test”, “mult”, “done” } of strings. The predicates 
Init and Next are 


Init = (f =1) A (pe = “test”) 


Next = ( (pe = “test”) 
^A (pd =1F i>1 THEN “mult” ELSE “done” ) 
A (F=f) A =i) 
vV ( Age="mult?) 
A (pe = “test” ) 
A (f =ixf) 


For this example, let us write a state s as [i +> s(i),f => s(f),pct> s(pe)]. 
The set of initial states consists of all states [i +> io, f > 1, pc + “test” | 
such that zo is an integer. The next-state relation includes the pair of states 


( [ir —6, fre 11, pers “mult”], [i = —7, f  —66, pe | “test” ) 
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because Next equals TRUE under the substitution 
i — —6, f— 11, pe — “mult”, 2’ —7, f’ — —66, pe’ — “test” 


The transition predicate Nezt is the disjunction of two formulas, each de- 
scribing a piece of code that generates a step. The first disjunct describes 
the if test; the second describes the bracketed statement labeled mult. Each 
of these disjuncts is the conjunction of four formulas. Three of them specify 
the new values of the three variables (their values in the second state) as a 
function of their old values. The other conjunct contains no primes and is 
an enabling condition—it is a state predicate that is satisfied by a state s iff 
there exists a state t such that (s,¢) satisfies the transition predicate. Such 
a disjunction of conjunctions is the canonical form of the predicate Next in 
a state-machine specification. 

The definition of the Next predicate of a state machine is usually built 
up hierarchically from simpler definitions. For example, we could define the 
formula Neat of Program 4 as Test V Mult, where Test and Mult are the 
transition predicates that describe the pieces of code labeled test and mult, 
respectively. There can be many ways to decompose the definition of a next- 
state transition predicate. For a state machine describing a multiprocess 
algorithm, Nezt is usually defined to have the form 3p € P : Proc(p), where 
P is the set of processes and Proc(p) describes the steps of process p. If a 
programming-language description of the algorithm has a variable x that is 
local to each process, then the state-machine description has a corresponding 
variable x whose value is a function with domain P, where z(p) represents 
the value of process p’s copy of the variable.* 


State-action machines are specified with an initial state predicate Init 
and a state-transition predicate Next, for each action a. A triple (s,a, t) 
belongs to the next-state set iff (s, t) satisfies Nerta. The set of all actions 
is usually partitioned into parameterized sets of actions; for each such set 
{a(z)} one specifies a parameterized state-transition predicate Nezt,(1). 


There are two standard methods of expressing fairness conditions: as 
fairness requirements on transition predicates [12] (usually disjuncts of the 
next-state transition predicate) and as temporal-logic formulas [23]. The 
temporal logic TLA [18] combines these two approaches by allowing fair- 
ness requirements on transition predicates to be written as temporal-logic 


“In some esoteric formalisms devised by computer scientists, functions are higher-order 
objects. In standard math, they are just sets of pairs; there is no fundamental difference 
between a number and a function. 
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formulas. In fact, it allows the entire specification of a state machine to be 
written as a single formula. 


5 Correctness 


I will illustrate how state machines can help reveal fundamental principles 
by considering what is usually (rather misleadingly) called correctness, as in 
“program correctness” or “proving correctness”. The area of correctness en- 
compasses algorithms and systems, not just programs, and it covers writing 
specifications whose correctness may never be proved. 

I will consider only state machines viewed as generators of state behav- 
iors. Most of the concepts introduced can be reformulated for state-action 
machines as well, but having actions in addition to states makes them more 
complicated. For simplicity, I will mostly ignore fairness. 

Many of the concepts presented here have been explored in the study 
of action systems and the refinement calculus, but with state machines de- 
scribed using programming language notation [5, 6]. 


5.1 Invariance 
5.1.1 The Inductive Invariant Method 


A state predicate is an invariant of a state machine iff it is satisfied by all 
reachable states—that is, by all states that occur in a behavior generated 
by the state machine. Invariants play an important role in understanding 
algorithms and programs. For example, a loop invariant is a state predicate 
L that is always true at the beginning of some loop in a program. Predicate 
L is a loop invariant iff AtLoop = L is an invariant of the program, where 
AtLoop is a state predicate asserting that control is at the beginning of the 
loop. 

A transition predicate T is said to leave invariant a state predicate Inv 
iff Inv A T = Inv’ holds, where Inv’ is the formula obtained from Inv 
by priming every state variable. This condition means that if a state s 
satisfies Inv and (s,t) satisfies T, then t satisfies Inv. A simple induction 
argument shows that if Inv is implied by the initial predicate Init and is 
left invariant by the next-state predicate Neat, then Inv is an invariant of 
the state machine. Such an invariant is called an inductive invariant of the 
state machine. The inductive invariant method proves that P is an invariant 
of a state machine by finding an inductive invariant Inv that implies P. In 
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other words, it consists of finding a formula Inv that satisfies 


Il. Init > Inv 
12. Inv A Next => Inv’ 
13. Inv > P 


It is easy to check that if P is an invariant of a state machine, then we 
obtain an equivalent state machine—that is, one that generates the same 
behaviors—by replacing the next-state transition predicate Next with P A 
Next or with P A Next A P'. 


5.1.2 Composition of Relations and Weakest Preconditions 


If A and B are relations on S, their composition A - B is defined to be the 
relation consisting of all pairs (s,¢) of states such that there exists a state 
u with (s,u) € Aand (u,t) € B. We define composition of transition pred- 
icates so it corresponds to composition of relations under the isomorphism 
between predicates and relations. In other words, we define the composition 
A- B of transition predicates A and B so that if A A and B © B, then 


A-B «= A-B. Letting x be the tuple (z1, ..., £n) of all state variables and 
letting v be a tuple (v1, ..., Un) of new variables, we can write 
A-B = 3v E€ Xi, ..., Un E Xn: Alv/z'] A B[v/z] 


where X; is the range of z;, and A[{v/z’] and B[v/z] are the formulas obtained 
by substituting v; for x, in A and w; for z; in B, for all i. 
We define the Kleene star operator for transition predicates by 


| 


A* Id V AV (A-A) V (A-A-A) VV... 

where Id is the identity predicate (x, = 21) A... A (£4 = £n). Thus, a 
state pair (s,t) satisfies A* iff there are state pairs (1,52), ..., (8j-1, Sj) 
satisfying A with s = sı and t = s;. The transition operator Init A Next* 
is satisfied by all state pairs (s, t) such that there is a behavior of the state 
machine that starts in state s and contains state t. 

A state predicate is a transition predicate that has no occurrences of 
primed variables. If A is a transition predicate and P a state predicate, 
then A- P is the state predicate that is satisfied by a state s iff there is a 
state t satisfying P such that (s,t) satisfies A. 

For a state predicate P and action predicate A, we define wlp(A, P) to 
equal the state predicate =(A-(—P)). (The wip stands for weakest liberal 
precondition [9].) A state s satisfies wlp(A, P) iff, for every t such that (s, t) 
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satisfies A, the state t satisfies P. The following properties of wip are easy 
to check, where A and B are transition predicates, P and Q are predicates, 
and Id is the identity transition predicate. 


W1. wlp(Id, P) = P 

W2. wip(A-B,P) = wlp(A, wip(B, P)) 
W3. If A = B then wilp(B, P) > wip(A, P). 
W4. QA A= P' iff Q > wip(A, P). 


Since Jd implies A*, W1 and W3 imply wip(A*, P) = P. Since A- A* implies 
A*, W2 and W3 imply wilp(A*,P) = wlp(A, wlp(A*, P)), which by W4 
implies that wlp(A*, P) is an invariant of A*. Hence, invariance conditions 
I2 and I3 (Section 5.1.1) are satisfied when Inv equals wlp(Next*, P). To 
prove that P is an invariant of a state machine, we therefore need only prove 
Init > wlp(Nezt*, P). 

The ability to prove invariance by proving Init > wlp(Next*, P) implies 
that the inductive invariant method is relatively complete. More precisely, 
if the language for writing state and transition predicates is closed under the 
operations of composition and taking the Kleene star, and if all valid formu- 
las in the language are provable, then the invariance of any invariant state 
predicate can be proved by verifying I1-I3 for a suitably chosen inductive 
invariant Inv. 


5.1.3 The Floyd-Hoare Method 


The most widely-studied invariance property is partial correctness. A partial 
correctness property of a program is specified by two state predicates: a 
precondition Pre and a postcondition Post. The property asserts that if 
the program is started in a state satisfying Pre and terminates, then its 
final state satisfies Post. Let Terminated be the state predicate asserting 
that a program is in a final state. The partial correctness property specified 
by Pre and Post asserts that Terminated = Post is satisfied by all states 
in all state-machine behaviors that start in a state satisfying Pre. In other 
words, it is an invariant of the state machine obtained by changing the initial 
predicate to Init A Pre. 

The Floyd-Hoare method for proving partial correctness [11, 16] anno- 
tates the program text by attaching a state predicate Pe to each control 
point c. It is a special case of the inductive invariant method in which the 
inductive invariant Inv is the predicate Vc € C : (pe = c) = Pe, where C is 
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the set of all control points and pc = c asserts that control is at c. For pre- 
and postconditions Pre and Post, condition I1 reduces to Init A Pre => Pini 
and I3 reduces to Prin = Post, where ini is the initial control point and 
fin is the final control point. To prove I2, the transition predicate Nest is 
written Jc € Neste, where Next, describes the operation at control point c. 
Condition I2 then reduces to verifying Inv A Next, = Inv’ for each control 
point c. 

For example, suppose the program has variables z, y, and z and contains 
the statement 


cx2=yt1; d:... 
Then Nezt, equals 
(pe =) A (p =d) A (z =y +1) A (y =y) A (2 =2) 
and the condition Inv A Next, = Inv’ reduces to 
Pe A (@ =yt1) A (y =y) A (2 = 2) > Pi (1) 
If Pe and Pg do not mention pc, then this condition is equivalent to 
P.[y+1/z] > Pa 


where P.[y+1/a] is Pe with y+1 substituted for z. This latter formula is the 
standard Floyd-Hoare verification condition for the assignment statement 
r=y+l1. 

If we replace x=y +1 by an arbitrary statement S, then (1) becomes 
P.A\ S = P}, where S is the transition predicate that represents S. This for- 
mula is the meaning of the Hoare triple {P.}S{Pq}. In general, decompos- 
ing condition I2 in this way for an arbitrary program yields the verification 
conditions for the various kinds of statements in the programming language. 

The relative completeness of the inductive invariant method, discussed 
in Section 5.1.2 above, implies standard results about the relative complete- 
ness of the Floyd-Hoare method for simple programming languages [4]. The 
general completeness result for state machines assumes that one can write 
predicates that describe the entire state. However, because computer sci- 
entists are so fixated on languages, they often consider approaches like the 
simple Floyd-Hoare method whose only state predicates are ones that can 
be expressed in the programming language. Thus, they write state predi- 
cates using only program variables and cannot mention parts of the state 
like pc. For very simple sequential programming languages, the Floyd-Hoare 
method is relatively complete even though its state predicates mention only 
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program variables. However, it is incomplete for a programming language 
with procedures, since completeness requires the use of state predicates that 
describe the calling stack. 

For concurrent programs, we are interested in a richer class of invariance 
properties. For example, mutual exclusion is the invariance of the state 
predicate asserting that two different processes are not both in their critical 
sections. The Owicki-Gries method [22] generalizes the Floyd-Hoare method 
to concurrent programs. It involves assigning a state predicate P? to each 
control point c of every process p. It is an instance of the inductive invariant 
method in which the inductive invariant Inv is the conjunction of all formu- 
las (pce(p) = c) = PP, where pc(p) is the current control point of process p’s 
program. Using a similar decomposition of the next-state transition pred- 
icate Next, condition I2 reduces to the Owicki-Gries method’s “sequential 
consistency” and “interference freedom” conditions. However, even for the 
simplest concurrent programming languages, this method is incomplete if 
the state predicates P? cannot mention pc. With pc considered politically 
incorrect, Owicki and Gries added dummy variables to the program to al- 
low the control state to be mentioned in state predicates. This makes the 
Owicki-Gries method complete for simple programming languages, since pc 
can be introduced as a dummy variable. 

The Owicki-Gries method is very easy to derive and to understand as 
an instance of the inductive invariant method, as long as one can talk about 
program control. However, it becomes rather mysterious when one refuses to 
do so because the programming language doesn’t have a way of expressing it. 
Dijkstra demonstrated how complicated the method can then appear [10]. 


5.2 Refinement 


The concept of a computing object Y refining another computing object X 
occurs in various guises. We sometimes say that Y implements ¥, and we 
may call ¥ and y the specification and the implementation, the abstract 
system and the concrete system, or the higher-level and lower-level specifica- 
tions. The most common example is ¥ a program in a higher-level language 
and y} its compiled version. As in the case of compilation, we may start 
with ¥ and refine it to obtain VY. We may also start with VY and derive VY 
as a higher-level or more abstract view of Y. For example, we may explain 
an algorithm Yy by finding a more abstract algorithm ¥ from which Y can 
be derived. 

For y to refine X, there must be a notion of a computation cy of Y 
refining a computation Cy of X. Let’s write cy X Cz to mean that cy refines 
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Cz. There are two basic notions of refinement. The first requires that V 
and YV be equivalent under refinement, so œ is a 1-1 correspondence between 
the computations of VY and of X. A popular example of this notion of 
refinement is bisimulation [21]. The second concept of refinement is that for 
every computation cy of Y there is a computation Cy of ¥ with cy X Cz. 

Both concepts of refinement have their uses. However, for discussing 
correctness, the second is the more appropriate one. Since we are here taking 
computations to be state behaviors, we define a relation « on behaviors to 
be a refinement of X by YV iff for every behavior ø generated by V there 
is a behavior 7 generated by ¥ such that o xr. We now consider how the 
relation œ is defined. 


5.2.1 Data Refinement 


Data refinement means replacing the data types used to describe the state 
machine ¥ by different data types—usually lower-level or more concrete 
ones. For example, ¥ might be defined in terms of a queue q that in y is 
represented by an array Arr, a pointer ptr to the queue’s first element, and 
the queue’s length len. 

A data refinement is specified by an abstraction relation R from the state 
set Sy of Y to the state set Sy of X. In other words, R C Sy x Sx. If o 
is the behavior sı — sg — ... in Sy and 7 is the behavior tj > t2 > ..., 
then we define the relation xr on behaviors by o xp T iff o and 7 have the 
same length and (s;,t¢;) E R for all i. We say that R is a data refinement 
of X by YV iff xr isa refinement of V by V. 

Let z1, ..., £n be the state variables of V and y1, ..., Ym be the state 
variables of Y, and assume that the x; and y; are all distinct. The relation 
R is then specified by a predicate R whose free variables are the z; and yj. 
If X has no fairness conditions, then œR is a data refinement if the following 
two conditions are satisfied, where subscripts are used in the obvious way 
to name the state machines’ defining predicates. 


R1. Inity A R => Initx 
R2. Netty A RA R! > Nert 
As observed in Section 5.1.1, if Inv is an invariant of state machine V, then 
we can replace Nezty by Inv A Nesty A Inv’. 
An important special case is when the abstraction relation R is a func- 


tion. In that case, R is specified by n functions %; of m arguments, where 
R equals 


(£1 = Ti(y1,---,Ym)) A... A (En = Tny, «++, Ym)) 
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Let F be the predicate obtained from a predicate F by substituting x; — 
Lily1,---,Ym) and x’; — Z;(y},---, ym), for each i. Conditions R1 and R2 
then become 


Rly. Inity => Init 
R2;. Netty = Neztx 


When written this way, the abstraction function is called a refinement map- 
ping [1]. In the example of refining a queue q by variables Arr, ptr, and 
len, the refinement mapping is defined so that q(A, p, l) equals the contents 
of the queue corresponding to Arr = A, ptr = p, and len = l. 

When the state machines have fairness conditions, to prove refinement we 
must also show that the fairness conditions of VY imply the fairness conditions 
of X. In general, this is easier to do for a refinement mapping than for an 
arbitrary data refinement. 


5.2.2 An Example of Data Refinement 


Starting from a state machine ¥, we can derive a state machine Yy that 
refines it by defining a suitable refinement mapping. As an instructive ex- 
ample, we derive a simple but important algorithm for alternately executing 
two operations A and B from a trivial algorithm. The trivial algorithm 
might be written in a programming language as: 


loop a:A; 6:B endloop 


For simplicity, let’s suppose that operations A and B access only a single 
variable z. This algorithm can be written as a state machine ¥ with 
Inity = (pe = a) A (£ = 20) 


((pe =a) A AA (pë = b)) 
V ((pe =b) A B A (pe! = a)) 


l> 


Nezt x 


for suitable transition predicates A and B that mention only x and for some 
initial value zo. 

Let us now refine the variable pc with two variables p and c whose range 
is the set {0,1}, defining the refinement mapping by 


pc = IF p=c THEN a ELSE b (2) 


T 


l> I> 


T 
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Since pc = a iff p = c, and pe = b iff p Æ c, and since A and B mention 
only z, we have 

Tnit = (p=c) A (w= 20) 

Nesty = ((p=c) AAA (p #2) 

V (pAe) ABA (p'=Cc')) 

These predicates define a state machine with variables p, c, and x. However, 
Next does not have the canonical form of a next-state transition predicate 
because its two disjuncts do not specify the values of p’ and c’ as functions of 
p and c. We obtain our algorithm JY be defining a canonical-form transition 
predicate Nexty that implies Neztx. 

Let © be addition modulo 2, so 1@1=0. Since p and c can equal only 
0 or 1, we have p Æ c iff p = c@1 or, equivalently, c = p@1. Each disjunct 
of Neztx is therefore satisfied iff either p' = p@1 and c’ = c, or p' = p and 
c' = c @1. The following transition predicate Nezty thus implies Nezty: 

Netty = ((p=c)A AA (p'=p@l) A (ce! =0)) 
V (pAe) ABA (p'=p) A (ec =c@l)) 
Let V be the state machine with this next-state transition predicate and 
with initial predicate Inity equal to Init x. 

We defined Nezty so it would satisfy R2, and Rl, trivially holds (be- 
cause Inity is defined to equal Init). Hence Y refines ¥ under the refine- 
ment mapping (2). Since the steps of a behavior of æ alternately satisfy 
A and B, and the refinement mapping leaves z unchanged, we deduce that 
steps of y also alternately satisfy A and B. Thus, like ¥, the state machine 
Y describes an algorithm for alternately executing A and B operations. 

Algorithm yY is an important hardware protocol called two-phase hand- 
shake [20]. A device that performs operation A is joined to one that performs 


B by two wires whose levels are represented by the values of p and c. 
Pp 


r 


A B 


—— 


C 


The first device performs an A operation when the levels of the two wires 
are the same and complements the level of p. The second performs a B 
operation when the levels of the two wires are different and complements 
the level of c. 

The key step in this derivation was the substitution of the expression pc 
for the variable pc in the initial and next-state predicates. Such substitu- 
tion is impossible in most languages for describing state machines, includ- 
ing programming languages. There is no way to substitute for pc in the 
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programming-language representation of X, since pc doesn’t appear explic- 
itly. Even if pc were described by a variable, it would make no sense to 
substitute the expression pc for pc in a statement such as pc := b. 


5.2.3 Refinement with Stuttering 


In data refinement, behaviors of state machine ¥ and the corresponding 
behaviors of its refinement Y have the same number of steps. More often, 
a single step of ¥ is refined to a sequence of steps of Y. As an example, 
suppose ¥ is a state machine representing a simple hour clock, described 
by a variable hour that cycles through the values 1, 2, ..., 12.° A simple 
refinement is a state machine Y representing an hour-minute clock, with 
variables hr and min, in which min cycles through the values 0, 1, ..., 59, 
and hr is incremented when min changes from 59 to 0. 

If we ignore the minute, then an hour-minute clock is just an hour clock. 
So, we expect Y to implement ¥ under the simple data abstraction defined 
by the refinement mapping hour = hr. However, if o is a behavior of the 
hour-minute clock V, then ox r only for a behavior 7 with 59 steps that 
leave the state unchanged between every step that increments hour—steps 
that are called stuttering steps. The state machine ¥ does not generate 
such stuttering steps. 

To describe this kind of refinement, we define the relation ~ on state 
behaviors by o ~ 7 iff 7 can be obtained from ø by adding or deleting 
stuttering steps. We can then define the refinement Xp for an abstraction 
relation R by o Xp7 iff there exists a state behavior p such that o op p and 
p~T. If R is defined by the refinement mapping hour = hr, then Xp isa 
refinement of the hour state machine by the hour-minute state machine. In 
such a case, we say that R is a data refinement with stuttering. 

In Section 2.4, we saw that we sometimes want to specify a system with 
a state machine in which some of the state is considered to be hidden. This 
is usually done by letting the machine’s state set S be the Cartesian product 
S? x S” of a set S” of visible (also called external) states and a set S” of 
hidden (also called internal) states. If Y and y are two such specifications 
with the same set S” of visible states, then YV is said to implement X iff 
every behavior of VY has the same visible states as some behavior of X. If Y 
is the abstraction relation defined by ((v,h), (w,j)) € V iff v = w, then Y 
implements ¥ iff V is a data refinement with stuttering of ¥ by Y. 

Proving data refinement with stuttering is similar to proving ordinary 
data refinement. In condition R2 or R2; of Section 5.2.1, we just replace 


5We are ignoring the physical time that elapses between ticks. 
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Next x by Nextx V Idx, where Idx equals (x, = 21) A -++ A (xl, = £n) and 
the x; are the state variables of X. However, stuttering can complicate the 
proof of the fairness conditions of ¥. 

In a wide variety of situations, from compilation to implementing a pro- 
tocol by a distributed algorithm, refinement is data refinement with stutter- 
ing. In most of these cases, the data refinement is defined by a refinement 


mapping. 


5.2.4 Invariance Under Stuttering 


We can reduce data refinement with stuttering to ordinary data refinement 
by simply requiring that a state machine’s next-state predicate allow stut- 
tering steps. For example, the refinement mapping hour = hr is a data 
refinement of the hour clock by the hour-minute clock because the hour 
clock’s state machine generates behaviors that contain 59 (or more) stutter- 
ing steps between changes to hour. 

Requiring the next-state predicate to allow stuttering steps is a special 
case of the general principle of invariance under stuttering®, which is that we 
should never distinguish between two behaviors that differ only by stuttering 
steps [17]. The idea behind this principle is that, in a state-based approach, 
the state completely describes a system. If the state doesn’t change, then 
nothing has happened. Therefore, two behaviors that differ only by stutter- 
ing steps represent the same computation. 

If the next-state relation M allows stuttering steps, then (s,s) is in M 
for all states s. Condition $3 in the definition of the behaviors generated 
by a state machine (Section 2.2) then implies that every behavior is infinite. 
A behavior that ends in an infinite sequence of stuttering steps is one in 
which the computing object represented by the state machine has halted. 
To disallow premature halting, we must add a fairness condition to disallow 
behaviors that stutter forever in a state in which a non-stuttering step is 
possible. (The requisite condition is weak fairness of the transition predicate 
Next \ aId, where Id is the predicate corresponding to the identity relation 
on the set of states.) 

Invariance under stuttering simplifies reasoning about refinement. How- 
ever, it may not be a good idea for other applications. 


This use of invariance is unrelated to its use in Section 5.1 
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6 Conclusion 


I have tried to show that state machines provide a simple conceptual frame- 
work for describing computation. Some of the unification provided by this 
framework may have passed unnoticed—for example, that there is no funda- 
mental difference between termination and deadlock. Much of the discussion 
has been quite superficial. For example, nothing was said about computa- 
tional complexity except that it measures the number of steps in a behavior. 
To measure complexity accurately enough so constant factors matter, one 
must decide what operations should be counted. When computers were 
slower, one counted floating point multiplications and divisions, but not 
additions and subtractions; today, memory references are usually what mat- 
ter. Deciding what operations to count means choosing what constitutes an 
individual step of the state machine. 

I have gone into some detail only in the area of correctness. Even there, 
much more can be said. For example, Hoare logic [16] was only touched 
upon. It can be explained as a way of considering a state machine Y} to be 
a refinement of a high-level state machine VY whose behaviors consist of at 
most one step, where s — t is a behavior of ¥ iff s is an initial state and t 
a final state of Y. The next-state predicate of X is Next}, ^ Terminated’, 
where Nezty is the next-state predicate of Y and Terminatedy is true iff 
y has terminated. 

I have used mathematics in a simple, naive way to specify state ma- 
chines. The one non-obvious idea that I mentioned is stuttering invariance 
(Section 5.2.4). There are other sophisticated ideas that simplify the math- 
ematics of state machines. One is to use a single state space for all state 
machines, in which a state is an assignment of values to all possible vari- 
ables. Variables not mentioned in the initial and next-state predicates can 
assume any values. This mirrors ordinary mathematics, in which writing 
xz +y—1 does not imply the non-existence of the variable z. The use of a 
single state space makes it easier to relate different state machines and to 
combine them in ways such as parallel composition. 

Many languages are expressive enough to describe any state machine 
and could thus also provide a uniform framework for describing computa- 
tion. The advantage of state machines is that they can be described using 
ordinary mathematics. Mathematics is simpler and more expressive than 
any language I know that computer scientists have devised to describe com- 
putations. It is the basis of all other branches of science and engineering. 
Mathematics should provide the foundation for computer science as well. 
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Appendix: The Definition of z(c) 


To define the set of pomsets generated by state-action machine, we now 
define the pomset 7(o) corresponding to a computation ø of the machine. 
This definition was mentioned by Pratt [24, Section 2.2]. 

Let o be the state-action computation 


For simplicity, assume that o is an infinite sequence. Modifying the de- 
finitions to apply to finite computations is straightforward but somewhat 
tedious. . 

We begin by defining o => r for a positive integer i and a computation 
T to mean that 7 can be obtained from o by interchanging a; with a;_}. 
More precisely, o Š 7 is true (for i > 1) iff a; # aj_1 and 7 is the same 
as o except with s;_1 = aps Si+1 replaced by s;i—1 ae pa $;41 for 
some state t. 

We next define the relation i -,7 to mean that we can obtain com- 
putations of the state-action machine by interchanging a; with œj—1, then 
with aj_2, ..., then with a;. More precisely, we inductively define i ~> j 
to hold iff either 


e i=j or 
e i < j and o -. 7 holds for some computation 7 of the state machine 
with 7, (j — 1). 


Finally, we define 7(a) to be the set {e1, e2,...}, where each e; is labeled 
by a;, with the partial order < defined by e; < e; iff i < j and i +, j does 
not hold. 
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